-
Notifications
You must be signed in to change notification settings - Fork 2.5k
feat: Automatic generation for rules file #5873
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
✅ No security or compliance issues detected. Reviewed everything up to a7e4e5b. Security Overview
Detected Code ChangesThe diff is too large to display a summary of code changes. Reply to this PR with |
|
Hey! I like this a lot, but I have a few questions:
|
Those are some great thoughts! The PR was getting a little big, so I was thinking off adding more of default modes stuff in a separate PR if you think that makes sense? For editing the rule creation prompt-- that's a great idea! Maybe I could add a "preview task prompt" button that compiles an editable preview of the rule creation prompt. I wasn't that pressed about it for this PR bc we have the user input box + I think the idea for the rule generator is that you would only run it once per repo. Another PR to build of this if we see rules taking off is making the magic rule generator additive instead of overriding! alright if I just start with this for now? |
Sounds good! |
daniel-lxs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - Focus: ${rule.focus}${alwaysAllowWriteProtected ? "\n - The directory has already been created for you" : "\n - Create the necessary directories if they don't exist"} | ||
| - Always overwrite the existing file if it exists | ||
| - Use the \`write_to_file\` tool to save the content${alwaysAllowWriteProtected ? "\n - Note: Auto-approval for protected file writes is enabled, so you can write to .roo directories without manual approval" : "\n - Note: You will need to approve the creation of protected directories and files"}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the prompt need to know whether alwaysAllowWriteProtected is enabled? I wouldn't think so.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I just read a little more. Zooming out I don't think this feature should be interacting with the alwaysAllowWriteProtected setting the way it is (or encouraging people to set it to true as part of this feature).
| general: { | ||
| path: ".roo/rules/coding-standards.md", | ||
| focus: "General coding standards that apply to all modes, including naming conventions, file organization, and general best practices", | ||
| analysisSteps: [ | ||
| "Examine the project structure and file organization patterns", | ||
| "Identify naming conventions for files, functions, variables, and classes", | ||
| "Look for general coding patterns and conventions used throughout the codebase", | ||
| "Check for any existing documentation or README files that describe project standards", | ||
| ], | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least in my testing this didn't seem to generate very useful rules. I think it might be worth tweaking the prompt, especially since this is the content that will end up in the system prompt for every one of the modes (including the custom modes). What do you think the most important information for the model to know is? What does Claude Code do?
| "Examine test files to understand testing patterns and frameworks used", | ||
| "Look for error handling patterns and logging strategies", | ||
| "Identify code style preferences and import/export patterns", | ||
| "Check for TypeScript usage and type definition patterns if applicable", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The typescript mention might be a little too specific?
| "docs-extractor": { | ||
| path: ".roo/rules-docs-extractor/documentation-rules.md", | ||
| focus: "Documentation extraction and formatting rules, including documentation style guides, API documentation patterns, and content organization", | ||
| analysisSteps: [ | ||
| "Check for existing documentation files and their formats", | ||
| "Analyze code comments and documentation patterns", | ||
| "Look for API documentation tools or generators", | ||
| "Identify documentation structure and organization patterns", | ||
| "Check for examples or tutorials in the codebase", | ||
| ], | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should have this option - it's only applicable in the Roo Code repo
| } | ||
| } | ||
|
|
||
| // Count all files in the workspace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we can use one of the existing ways of listing files in the workspace so the logic is consistent
| exists?: boolean | ||
| } | ||
|
|
||
| export const RulesSettings = ({ className, hasUnsavedChanges, ...props }: RulesSettingsProps) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Product-wise, I kind of feel like it's more magical (and simpler) if we just have a single button to automatically generate rules and it's smart enough to generate relevant ones for the project. The user will always have the ability to decide which of the files to keep or not, and they'll likely have the option to approve each one as well with the default of auto-approving writes to protected files turned off (in this case seems reasonable to review the output).
I also think they can add to .gitignore later if they want, but in general I would think that the default should be that these rules files are not gitignored and that teams would collaborate on them to build up a collection of project-specific rules. So probably wouldn't have that setting in the UI/prompt either.
|
Just finished reviewing. The more I think about it, I'm really interested in the angle where there's a single button that intelligently proposes a set of rules files that makes the modes all work better together in the project, and what the ideal prompt would be for that. |

Add magic rules generation feature for automated codebase analysis
Feature Loom: https://www.loom.com/share/6dc1eae6a5774008be760b590091792e
Important
Introduces automatic generation of mode-specific rules with UI integration, configuration management, and comprehensive testing.
generate-rules.ts.RulesSettings.tsx..gitignoreauto-integration and file overwrite warnings.global-settings.tsto includerulesSettingsfor storing rule generation preferences.RulesSettingscomponent toExperimentalSettings.tsxfor managing rule generation settings.generate-rules.test.tsandrulesGenerator.test.ts.make-rulescommand to context menu incontext-mentions.ts.This description was created by
for bb59cf9. You can customize this summary. It will automatically update as commits are pushed.